Fix avif odd width/height handling #2130
Conversation
|
Given that the Based on that crates documentation, the relevant formula is: r = 1.164 * (y - 16) + 1.596 * (cr - 128)
g = 1.164 * (y - 16) - 0.813 * (cr - 128) - 0.392 * (cb - 128)
b = 1.164 * (y - 16) + 2.017 * (cb - 128) |
It's an option, I was also thinking about adding the yuv422 -> rgba and yuv400 -> rgba algorithms to |
| width, | ||
| height, | ||
| rounded_width, | ||
| rounded_height, | ||
| &src_format, | ||
| Some(strides), | ||
| &src_buffers, | ||
| &dst_format, | ||
| None, |
There was a problem hiding this comment.
It may be worth seeing whether a non-None value here would enable support for odd sized images
|
Any updates on this issue? Lots of avif images out there with odds dimensions. |
This is correct only for Bt.601 matrix with limited range which is not really common nowadays, since it was replaced by Bt.709 matrix in most cases.
|
I license past and future contributions under the dual MIT/Apache-2.0 license,
allowing licensees to choose either at their option.
Related issue
This PR fixes the InvalidValue error in dcv_color_primitives when trying to decode odd width/height AVIF files and changes PixelLayout::I422 to todo!() since it's not supported by dcv_color_primitives (source).
It's a bit hacky but dav1d's output buffer's width/stride seems to always be a multiple of 128 (not too sure about this though) so no need to account for that just increase the width provided to the convert_image by 1 if it's odd.
And for the height add a padding row of zeros to the source luma buffer.
And at the end copy only the actual width and height parts of the dst buffer while discarding the padding.